When displaying, monitoring and exploring a complex system, a Model-View-Controller architecture is often adopted. The Model encapsulates all the complexities of the system and presents a crisp interface for interaction with it. The View manages the translation of system information to its presentation in the user interface, and the Controller manages interactions among the user, the model and the view. Frequently, however, there are changes to the type and form of the information that the View presents. It may change as the task the user performs evolves during the lifetime of the task. Or it may change depending on the specific task the user is performing.
For example, creating, executing and monitoring distributed applications that run on multiple hosts and are connected with a high speed data transport mechanisms such as the CLIO/S product from International Business Machines Incorporated of Armonk, N.Y., requires several views of many types of information. During initial development of the application, the user is interested primarily in the structural representation of the data flow among various applications of distributed hosts. When the application is initially run (before it is completely debugged), the user is interested in both the states of the components and the interconnections between components (for example, if a component appears to be stalled, it may be because it is not running correctly or it may be because the data it requires is not being delivered, or the data is generating is not being consumed). Once the application is complete and the user starts running it, the user is more interested in the specific state of the components of the application (whether job steps are running or stalled, whether data transfer is occurring, and, if so, the transfer rate). When a distributed application is complete and is being used in production, the user is less interested in the specific state of the components of the applications and more interested in an overall summary of the state of the distributed job. Controlling the overall application involves views that are similar to those required for monitoring because improperly affecting the control flow (such as abnormally terminating a component or restarting one out of sequence) can have a ripple effect that produces undesirable effects.
Unfortunately, a single View is not well suited to present all types of information. Graphical views are good for structure, but tend to become cluttered and unusable as specific textual information is added to them. List-type textual displays can present a lot of detailed information in a compact space, but give no information about structure. List-type textual displays are also ineffective for representing summary information (such as the progress the job is making toward completion). Measurement displays (such as bar graphs or meters) are ideal for presenting overall summaries, but give no information about structure or detailed states.
This problem has been addressed in the past in two ways. The first has been to choose a single view and add the additional information to it as needed. Typically a graphical view is chosen because it is initially easier to visualize the entire system, and mechanically it can accept the additional information that will be required later (it is easier to add text to a graphical view than graphics to a textual view). There is a practical limit to how much detailed information can be added to a graphical view as the screen real estate becomes cluttered and the information is obscured. In order to utilize this approach, a user must maintain the amount of detailed information below some threshold by selectively closing old detailed information as new information is requested.
The second approach has been to replace the View object in the Model-View-Controller configuration as the type of information the user is interested in changes. When the user is no longer interested in the structure of the distributed application and becomes interested in the detailed state of the components, the structure view is replaced with a detailed state view. The problem with this approach is that the new view must be recreated on demand and inserted into the Model-View-Controller configuration. Even if the old view is preserved when the user switches out of a particular mode (switching from structure to state views, for example), there is expense involved when the old view is reused (switching back to structure from state). The old view must be reconnected with the model and controller, and it must be made current to reflect any model changes that occurred when it was not active. This expense is enough to inhibit the user from switching between views freely.